This invention relates to the control of routing tables at switching nodes in a network. In particular, the invention relates to control plane interfaces for a device driver and a network interface device by means of which routing tables can be updated.
Various protocols are known in the art that allow the routing tables of network entities to be remotely accessed. For example, the Simple Network Management Protocol (SNMP) can be used to manage objects on a network and to query the routing tables of objects such as switches and routers. SNMP is an application layer protocol and requires a software agent (typically of the operating system) to provide routing information in response to queries from managing entities on the network. There are also many proprietary protocols which allow network administrators to manage the routing tables of suitable switches, such as HP Virtual Connect.
Other protocols, such as Multiple VLAN Registration Protocol (MVRP), have been developed to allow routing tables to be updated so as to define new VLANs and configure existing ones. MVRP is a data link layer protocol (layer 2 of the OSI model) which provides an interface for managing one or more virtual networks over a physical network infrastructure.
FIG. 1 illustrates a typical network configuration. A number of network entities (such as servers 103, desktop computer 101, network printer 102 etc.) are connected to one another by means of a network which comprises interconnects 107 and switches 104, 108. Data packets are routed over the network from one entity to another by the switches. For example, if desktop computer 101 wishes to send data to printer 102 it will transmit data over the interconnect to switch 104 which will direct the packets to printer 102. Similarly, if data packets arrive at gateway 105 from the internet 106 for one of the servers 103, switches 104 and 108 will act so as to direct the incoming packets to the appropriate server.
A network switch maintains a routing table relating the network address of each entity to the physical port supporting an interconnect over which data packets should be directed so as to reach that entity. Thus, each switch knows how to route each packet from the entries in its routing table. Generally, network protocols define mechanisms by which a switch can learn new routes and make new entries in its routing table—often using Address Resolution Protocol (ARP), which allows a switch to look up the hardware address of a host when only the network address of the host is known. This allows a switch to, inter alia: handle packets for new entities on the network; modify the routing of packets for a particular entity where there is more than one possible route between the switch and entity so as to optimise network traffic; modify the routing of packets in accordance with a quality of service (QoS) protocol.
However, it is now commonplace for each physical network entity to support multiple virtualised systems. For example, a server can support multiple guest operating systems managed by a hypervisor, with each guest operating system supporting multiple application endpoints having their own network addresses. A blade server (shown in FIG. 2) is more complex still, with a single server chassis 201 comprising multiple “blades” 203, each having one or more processors 206 and a network interface device 205. Server chassis 201 includes one or more network interface devices 204 by means of which the server can communicate with a network. Each blade is a self-contained server module typically supporting a hypervisor 208 within software domain 207 and one or more guest operating systems 209 managed by the hypervisor. Thus, a single blade server can support many guest operating systems. This additional complexity within a network entity requires it to support additional routing tables so as to allow packets received over the network to be routed to the correct endpoint of the correct guest operating system (and in the case of a blade server) of the correct blade.
A blade server therefore generally has a routing table at the one or more network interface devices of the server chassis, a routing table at the network interface devices of each of the blades, and a routing table at the hypervisor of each of the blades. Each of these must be maintained in a similar manner to those of a hardware switch situated between the interconnects of a network.
A particular difficulty is presented when a live guest operating system migrates from one blade to another, or from one server to another. In order to maintain the integrity of the connections of that guest, all the affected routing tables (of the hardware switches, network interface devices and hypervisor) must be updated as quickly as possible so that network traffic to and from the guest is appropriately redirected. However, most conventional mechanisms for modifying routing tables are proprietary protocols restricted to managing the routing tables of hardware switches supporting the proprietary protocols. The network interface devices and hypervisors of servers and other computer systems do not provide an efficient mechanism by which their routing tables can be updated.
In conventional systems, on migrating a guest operating system from one system (blade or server) to another it might be possible in some networks to update the routing tables of certain switches using management protocols provided by the switch vendor, but it is not possible to update all the affected routing tables—including those supported at the network interface devices of servers and in software—by means of a single mechanism. Thus, any changes to the routing tables due to the migration (say) of a guest operating system slowly filter through the network by means of outdated mechanisms such as ARP. In a typical network, ARP can take 30 seconds to update the affected routing tables, even when the fabric speed is 1 Gbps or more. This can prevent guests being seamlessly migrated between hosts, which is a particular problem in server farms that are becoming increasingly virtualised and strive to minimise the downtime of their servers.
It would be therefore be useful if there were a mechanism by which all the affected routing tables in a network—in particular those of virtualised servers—can be updated in response to server configuration changes or other network changes which have an impact on packet routing.